I was wondering if the above message means that there is a problem with the hard drive? I have installed Version 2.0 consumer image (not beta) and do not get the error message but when I install the latest Hijack (431) after every boot and when first accessing the Hard disk the error message appears. Oddly, it seems to play tracks OK regardless of the error. My player is a Mk 2a. Please advise me on what is causing this error message.

The message probably actually says this: hda: disk error: read_intr

Attention to accuracy can be important when seeking help here.

This particular message is not a big deal unless you see it often. The Linux IDE driver (which I wrote) will retry the failed command. Dunno why it fails the first time for you though.

-ml

Oops! I apologise for mis-quoting the error message, I was trying to remember what the message was as the machine was not in front of me when I posted the original query. The error message does seem to be displayed whenever I select a different playlist and set it to play, which I guess means every time it makes an initial read of the disk, oddly though it doesn't seem to display the message when it reads each track in the playlist, just the initial read for the playlist. (Incidently it did this when I loaded Hijack version 426 as well, which was why I re-downloaded the ver 2.0 consumer image and reflashed the machine with it and then downloaded and installed Hijack 431, so I was surprised when it did it again.)

Hijack displays the message, but the error is occuring even without Hijack installed -- you just don't get an on-screen message when using the stock v2 software. More information will be available on the serial port output regardless, which is where you should be looking now.

I have included here the boot log from Hyperterminal as (I believe) was suggested to allow further diagnosis of the problem.

empeg-car bootstrap v1.02 20001106 ([email protected])
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.17-rmk5-np17-empeg52-hijack-v431 ([email protected]) (g
2.95.3 20010315 (release)) #2 Tue May 24 19:50:51 EDT 2005
Processor: Intel StrongARM-1100 revision 11
Checking for extra DRAM:
c1000000: wrote ffffffff, read e91ba9f0
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 30102211) 16MB DRAM
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15008k/16M available (984k code, 20k reserved, 368k data, 4k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA110
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 636f6972 'rioc'
Tuner: loopback=0, ID=-1
Scheduling custom logo.
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0005400).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: IBM-DJSA-220, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: IBM-DJSA-220, 19077MB w/1874kB Cache, CHS=38760/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman ([email protected])

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:26:08:a
3
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...hange_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initTimezone: Australia/Adelaide
Hijack: intercepting config.ini

hijack: removed menu entry: "Serial Port Assignment"
khttpd: listening on port 80
kftpd: listening on port 21
player.cpp : 579:empeg-car 3.00-alpha8 2004/07/07.
hda: read_intr: status=0x59
hda: read_intr: error=0x40
end_request: I/O error, dev 03:03 (hda), sector 0
Prolux 4 empeg car - 2.1490 Jul 7 2004
Vcb: 0x4073a000
hda: read_intr: status=0x59
hda: read_intr: error=0x40
end_request: I/O error, dev 03:03 (hda), sector 0

Well, Mark, I tried your suggestion, (thankyou heaps) but I think it didn't work (see the log below) and so I guess I am faced with having to buy a new drive. No really big deal I guess, since I always planned to put a much bigger drive in the Empeg anyway. Just means the need is a bit more urgent now. Thanks again for your help, I know you must be a very busy man, so that makes the time you give here so much more appreciated.

(This is the log while trying to fix the problem)
empeg:/empeg/bin# dd if=/dev/zero of=/dev/hda3 bs=512 count=1
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=133057, sector=0
end_request: I/O error, dev 03:03 (hda), sector 0
dd: /dev/hda3: Input/output error
1+0 records in
0+0 records out
empeg:/empeg/bin#

(After next boot - this part of the log seems to confirm it)
player.cpp : 385:empeg-car 2.00 2003/04/01.
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=133057, sector=0
end_request: I/O error, dev 03:03 (hda), sector 0
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=133057, sector=0
end_request: I/O error, dev 03:03 (hda), sector 0
Prolux 4 empeg car - 2.1434 Mar 26 2003
Vcb: 0x4086d000
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=133057, sector=0
end_request: I/O error, dev 03:03 (hda), sector 0

Well, try again with something a little more drastic:

cat /dev/zero >/dev/hda3

(it will eventually fail with "access beyond end of device" or some such dribble, but it should NOT fail with the same error you've been getting thus far).

Thanks Mark, you're amazing! It Worked! What does that last command actually do, if I might ask, for future refernce?

Fills hard disk partition "hda3" with zeroes, if I understand correctly...

Thankyou Tony. However, I don't understand how that fixed the issue. (I am in IT 2nd / 3rd level support with a large international company, so I have a good technical background but in Windows, not Linux) Maybe I don't understand the actual nature of the error in the first place?

If I understand correctly, the idea was to trigger bad sector remapping mechanism done by disk firmware, but only on writes. Of course, old data is lost and this only works thanks for the fact that the partition in case holds data that the player software replaces dynamically.

The first one only erased the first 512 bytes. The second command erased the entire (EDIT) partition.

Yes the intention was to let the drive automatically map out the bad sectors which only occurs when the device is written to.

Like the others said, it forced the drive to rewrite the track containing the bad sector, at which time the drive itself either repairs the bad bits or remaps the sector/track to a factory "spare" designated for such purposes.

Sometimes writing only the reported bad sector won't work -- as in the first attempt here. The reason for that is that drives don't actually work on a per-sector basis anymore, and so writing the entire "track" is required to "fix" it. But nobody other than the drive itself knows what a "track" is, so the second command I gave you simply nukes the entire partition, hoping that this will include enough of the physical "track" to get the job done.

In the course of this, you will have lost your radio presets, equalizer settings, and per-track sound profiling data that the player automatically builds up. All of that stuff was on /dev/hda3 somewhere. No biggie, but a minor nuisance for some.

Cheers

Thanks to all of you, that does explain it very clearly. My sincerest thanks to Mark in particular for sorting this out for me. I have made a note of this for future reference should I ever need it again.

Should go into the FAQ, or be made sticky here.

Can I just make the request it goes in the FAQ if anywhere? After a while too many sticky posts just get annoying. Particularly on forums where the first half of the first page of posts are sticky.

Even the first few here annoy me a bit when I'm looking for new threads/posts.

I'm confused. Exactly what do you want in the FAQ?

It does work so well connotatively, though. The implication that it acts as the first drop of rain warning of a coming storm is compelling, especially since several definitions come so close to what he means, even if none of them really quite backs it up.

Maybe now with this "perpendicular storage", the definition meaning "to fall headlong" will come into use.

Naw, Most drives now have bad ( and remapped ) sectors from the factory, and they then last for years.

The only way to know for sure about impending drive failures is to watch the S.M.A.R.T. data from smartctl.

Cheers

Oh... and...

Quote:
The only way to know for sure about impending drive failures is to watch the S.M.A.R.T. data from smartctl.

Wouldn't new bad sectors suddenly appearing on the disk trigger SMART errors anyway?

S.M.A.R.T. monitors a hell of a lot more than simply a count of bad sectors, Tony.

Cheers

Yeah, but his point is that you're saying that SMART is the only indicator of a failing drive, but if bad sectors trigger SMART to say that the drive is failing, then the bad sectors themselves indicate a failing drive, regardless of other indicators. I don't think that's 100% accurate, but that's what he's saying.

Hey, Mark...

If you had a bad sector in the section that stored the current playlist order on the scratch partition, what would the command be to zero THAT out?

For instance, this command...

dd if=/dev/zero bs=512 seek=4096 count=28672 of=/dev/hda3

... zeroes out the statistics. What would zero out the stored playlists without erasing the EQ data?

I have a bad sector on the scratch partition where the current playlist order is stored. I am planning to get a new drive once I get settled in a new address. But for now I want to force it to map out the bad sectors in that section while I wait.

(I know, I argued specifically against this earlier in this very thread. I swear: If this works for me and the drive doesn't go completely south because of it, I will FAQ this.)

Damn.

Looks like I need to spend the cash on the new hard disk, then.

try zeroing the partition first. The player code does single sector I/O usually on the scratch partition, and that isn't good enough since the drive itself only reads/writes tracks.

Cheers

Okay, I'll give it a shot while I wait for the new drive to arrive. It means losing my EQ settings, but I can write those down.

If I recall, what I lose by zeroing the whole partition is:

- EQ settings
- Play counts, track overviews, and other per-track statistics
- The current running order/playlist (this is the thing that's not getting saved properly so it's already gone)

Anything else?

Again, my own FAQ answers me:

Tuner presets and bookmarks. I'm moving to Seattle so tuner presets I was gonna change anyhoo. And I don't have any bookmarks I'm worried about.

Okay, gonna try it.

Okay, it worked. Hm.

Before I FAQ this as I promised, I'll need to run all those SMART tests on the player to be sure the hard disk is in working order.

Incidentally, what indicated a disk problem to me was Hijack telling me "HDA: LOST INTERRUPT" each time I selected a down-down-down shuffle, and subsequent not-remembering-that-playlist-across-reboots. Selecting a smaller playlist would sometimes work without giving me the error and would be fine across reboots. I determined: Bad sector somewhere in the dynamic data partition. Not cable/header trouble because it had no problem reading the song files and playing them back. I reseated the cable, double checked its crimping, double checked the header, and switched the connector anyway to be sure, but no change.

But since it let me zero-out HDA3 without giving me any errors (either on the screen or in the console) and the player seems (cross fingers) to be working perfectly now, then should I assume that the disk is really fine at the hardware level and there was something ELSE wrong I'm not understanding?

Would something like a power failure or a software glitch that causes a reboot, during a dynamic-data-write, cause this kind of error?

And by the way, Mark...

THANK YOU for all your incredible expertise on this topic. We are truly fortunate to have the "Linux IDE Guy" around helping us all out. You are, and always have been, The Man.

Thanks for figuring out those offsets, Peter. I had just returned from a long (11 hours, 10 caches, 1035KM) drive, and my paltry reasoning skills were not functioning yet (and still probably aren't!).

Tony.. as you noted, you still oughta try a S.M.A.R.T. "long" test on it. It might really be bad still, but what you have done often recovers things nicely.

cheers

Thanks, I'm curious if the problem could possibly be all-software. I figured the errors I was getting were only possible as hardware errors.

Oh, and thanks, Peter and Mark, for those command lines. I updated the faq entry on clearing the dynamic data with those.

I'm still reserving judgement about a new FAQ on using the zero-out command as a workaround for bad sectors. Haven't gotten to the SMART tests yet. Still in a transitionary phase in my relocation and don't have time to run the tests just now.

Well, then I'm not so embarrassed for buying the new hard disk, then.

Well, as long as the new hard drive has a larger capacity, you can always say you were upgrading...

The logs retain error info long after errors are repaired. The report you posted shows old information.

It also shows you launching a "long" selftest, but I don't see the results of that test afterwards.. did you wait an hour and then redo the "smartctl -l selftest" command? I see one instance of that right after issuing the "-t long" command, but it doesn't show the results of the "-t long", which means the selftest was still happening (or the unit got powered off or something before it completed).

The selftest commands ("-t long") execute *in the background*, and take a while to complete.

Cheers

Damn. I thought I'd waited the 55 minutes it told me to wait.

Guess I'll do it over again.